Raid controllers are often used in data storage systems. Even though a Raid controller uses redundant information to withstand disk-loss, it is still possible for a Raid system to fail and lose data. Raid mirroring is a technique for reducing this risk by copying data between two sets of system drives (SDs)—often referred to alternatively as logical units (LUs)—either within a single Raid system or in two separate Raid systems, possibly at geographically separate sites. Each mirror has a primary SD and a secondary SD. The server writes data to, and reads data from, the primary SD; the Raid controllers automatically copy newly written data to the secondary SD.
If a primary SD is ever lost, an engineer can either break the mirror and discard the old primary SD, or can switch mirror roles, so that the old secondary becomes the new primary and vice versa. In either case, to access and updated previously-stored data, the file server must now use the new primary in place of the old one.
A Raid mirror can be synchronous or asynchronous. Whether a mirror is synchronous or asynchronous determines its behaviour when the file server writes data, but not when it reads data. In a synchronous mirror, the Raid controllers copy data to the secondary SD as soon as the file server writes it to the primary; in an asynchronous mirror, data is initially written only to the primary, and the changed parts of the primary are periodically copied to the secondary SD, typically once every few hours. This copying process is referred to as synchronizing the mirror.
Although SDs are typically larger than disks, they are typically smaller than the filesystems that customers usually want to create. Therefore, file servers such as the BlueArc Titan™ file server typically amalgamate multiple SDs into a larger pool of storage referred to as a span.
File servers may be aware of Raid mirroring. In the BlueArc Titan™ file server, the subsystem that manages spans (referred to as the Span Manager) knows about both primary and secondary SDs. If it detects that mirror roles have been switched, it will automatically stop using the old primary and start using the new one. This process is referred to as “failing over” from one SD to another.
The process of controlling the SDs that the server will use is referred to as “licensing.” The file server may be “licensed” for some SDs and “unlicensed” for other SDs. For example if SD “A” is mirrored to SD “B” and SD “B” is mirrored to SD “C”, then SDs “A” and “C” may be licensed and SD “B” may be unlicensed in order to prevent the server from using SD “B.” In the BlueArc Titan™ file server, with very few exceptions, the server ignores unlicensed SDs, and it automatically loads any pre-existing spans from, and mounts filesystems on, licensed SDs.
When setting up a mirrored system, an engineer typically first sets up mirror relationships on the Raid controllers and then manually configures the SD relationships into the file server. The file server can use the SD relationships to fail over to the correct SD when mirror roles change. However, manual configuration of SD relationships into the file server can be difficult and error-prone. For example, given twenty primary SDs and twenty secondary SDs, it can be difficult for the engineer to tell which secondary corresponds to which primary and so it can be difficult for the engineer to correctly configure the SD relationships into the file server.